This application is related to the following co-pending U.S. patent applications:
U.S. patent application Ser. No. 09/483,123 entitled, A PROGRAM-DEVELOPMENT ENVIRONMENT FOR USE IN GENERATING APPLICATION PROGRAMS, filed Jan. 14, 2000;
U.S. patent application Ser. No. 09/483,760 entitled, METHOD AND APPARATUS FOR RESOLVING DIVERGENT PATHS IN GRAPHICAL PROGRAMMING ENVIRONMENTS, filed Jan. 14, 2000;
U.S. patent application Ser. No. 09/483,759 entitled METHOD AND APPARATUS FOR DETECTING AND RESOLVING CIRCULAR FLOW PATHS IN GRAPHICAL PROGRAMMING SYSTEMS, filed Jan. 14, 2000; and
U.S. patent application Ser. No. 09/483,124 entitled, PROGRAM OBJECT FOR USE IN GENERATING APPLICATION PROGRAMS, filed Jan. 14, 2000.
1. Field of the Invention
The present invention relates generally to the field of computer programming and, more specifically, to software development environments.
2. Background Information
To generate a software program that can be executed or run by a computer, a software developer or programmer typically chooses a programming language, such as BASIC (Beginner""s All-purpose Symbolic Instruction Code), Fortran, C, etc., and writes source code using the keywords, syntax, variable names, data structures, etc. defined by the selected programming language. Each programming language typically defines its own unique syntax and keywords for performing various functions. After the source code has been written, it is typically converted by a compiler into a machine readable format that can be understood by the computer (e.g., object code). If the developer used incorrect keywords or syntax, the source code cannot by compiled successfully.
The source code is typically written with a text editor and organized into a series of lines of code. Although simple programs may only need a few lines of code, complex programs often consume hundreds, thousands or tens of thousands of lines of code. Significant portions of code, moreover, are often required just to generate displayable user interface images or forms, such as text boxes, command buttons, etc. that can be displayed by windows-based computer systems, such as personal computers running the Microsoft Windows(copyright) series of operating systems from Microsoft Corporation of Redmond, Wash. Furthermore, significant editing is often required to make even relatively minor adjustments to such user interface elements (e.g., moving, re-sizing, etc.).
In order to simplify the creation of such user interface images or forms, Microsoft developed and released a programming system known as Visual Basic(copyright). Visual Basic includes a language engine for executing text-based programming statements, and a forms layout package having a plurality of objects or icons representing common user interface elements, such as text boxes, radio buttons, command buttons, scroll bars, etc. When a developer selects one of these objects from a tool palette and places it onto a form window, Visual Basic automatically creates corresponding code to support that object. By eliminating the need to write code just to display conventional interface elements, Visual Basic greatly simplified the creation of programs to be run on Windows-based platforms. These objects are typically stored in one or more dynamic link libraries (DLLs) that are loaded and run as necessary at application run-time. Since Visual Basic is an xe2x80x9copenxe2x80x9d programming languages, meaning that its syntax and command structures are known and available, third-parties have created and marketed a whole range of objects that can be added to a Visual Basic forms window to facilitate the creation of all sorts of different application programs.
With the release of Visual Basic 4.0, Microsoft extended Visual Basic to support software constructs that have certain object-oriented features by basing this release on its Component Object Model (COM). With Visual Basic 4.0, a new type of object, often referred to as a COM or ActiveX control or object was defined. A COM or ActiveX control is basically a component program object based on Microsoft""s COM technologies, which can issue or raise events. With Visual Basic 4.0 and later releases, a developer similarly uses a forms layout package to drag and drop one or more ActiveX controls onto a form window. In addition, by double-clicking an ActiveX control on the form window, a code window is displayed. Inside this code window, the developer may insert text-based programming code to handle the events raised by the respective ActiveX control (i.e., an event handler). This code must comply with the syntactical and keyword constraints defined by Visual Basic in order for it to be properly executed at application run-time. By writing these event handlers, a developer can cause various ActiveX controls to share information and otherwise interact with each other greatly facilitating the creation of application programs.
FIG. 1 illustrates a conventional Visual Basic work space 100 that may be displayed on a computer screen. The work space 100 includes a Form window 102 and a tool palette 104. The tool palette 104 contains a plurality of icons, which represent individual controls, including a vertical scroll control 106 and a text label control 108, among others. A developer may select any of the controls contained on palette 104 to cause the selected control to appear on the Form window 102. By selecting the vertical scroll icon 106, for example, a corresponding vertical scroll image 110 is displayed on the Form window 102. A text label image 112 may be placed on the Form window 102 in a similar manner. At this point, however, there is no inter-relationship between the objects corresponding to vertical scroll image 110 and text label image 112. In order to establish some such relationship (e.g., causing the text label to display the current position of the vertical scroll), the developer must write a subroutine (e.g., an event handler). Each line or statement of the subroutine, moreover, must conform to the syntax and keyword commands of the underlying programming language (e.g., Visual Basic). Specifically, the developer selects the vertical scroll 110, thereby causing a code window 114 to be displayed on screen 100. Inside the code window 144, the developer writes a text-based subroutine 116 that causes the output of the vertical scroll 110 to be displayed in the text label 112.
When this program is subsequently run, images for the vertical scroll bar 110 and the text label 112 will appear on the screen of the user as part of a user interface. The text label 110, moreover, will display the position of the vertical scroll bar 110 (e.g., xe2x80x9c2256xe2x80x9d). If the user moves the slider bar of the vertical scroll, the contents of text label change to display the scroll bar""s new position (e.g., xe2x80x9c3891xe2x80x9d). As shown, with Visual Basic, the developer need not xe2x80x9cwritexe2x80x9d any code to cause the vertical scroll bar image 110 or the text label image 112 to be displayed on the computer screen during run time. In addition, during the programming phase, the developer may move and re-size these user interface elements simply by manipulating their appearance on the Form window 102 (e.g., with a mouse) in a conventional manner. Due to the relative ease with which application programs having user interface elements can be created, Visual Basic has become a highly popular programming tool. However, in order to develop a meaningful application program (i.e., one in which there is some inter-relationship between the user interface elements), the developer must write, in a text-based format, one or more subroutines. Thus, the developer must learn and is limited by the syntax and keyword structures of Visual Basic.
In addition to Visual Basic and its related products (e.g., Visual C++, etc.), several companies have created software development tools that are almost entirely visually oriented. That is, using these tools, a developer can create an executable application program without having to write a single line of text-based code. For example, National Instruments Corporation of Austin, Tex. has created a programming tool called LabVIEW(trademark) for creating virtual instruments primarily for use in the instrumentation industry. Hewlett Packard Company of Palo Alto, Calif. has similarly created a programming tool called HP VEE for generating software programs for use in the electronic testing and data acquisition industries.
HP VEE provides a work area in which a developer can create a data flow diagram. The developer typically selects the objects for inclusion in his or her program from a pull-down menu. HP VEE provides a fixed number of these objects which have been tailored to provide functionality commonly used in the data acquisition industry. The developer may then xe2x80x9cdrawxe2x80x9d data lines between these objects in the work area. In response to drawing these lines, HP VEE creates program steps that transfer data or other information between the respective objects. The developer must perform all of this graphically within the work area.
For developers working in the data acquisition field, HP VEE is a useful programming tool. There are some disadvantages nonetheless. For example, to implement functionality that the pre-defined objects do not provide, the developer must typically create a completely new object. Since this can take a significant amount time, it is often not done, unless the desired functionality is critical to the application program. Accordingly, some application programs lack functionality that the developer would have preferred to include. In addition, a graphical approach is not always the most expeditious way to represent or implement certain programs or subroutines.
Briefly, the invention relates to a particular program object for use in developing application programs through a program-development environment. Using the program-development environment, a developer graphically specifies a flow diagram that represents the logical operation of the application program. The program object, which may have a corresponding symbolic representation for display within the flow diagram, is configured to perform repeating functions and to issue a plurality of ready events, and is preferably used to define loop procedures within the application program. According to the invention, the developer may specify an event handler procedure that is responsive to at least one of the ready events of the repeating program object either through graphical inputs or textual inputs to a computer. The resulting event-handler procedure is then incorporated within the application program and may be called upon at application run-time. With the repeating program object of the present invention, the developer may thus use the most expeditious method (graphical or textual) for specifying a desired event handler procedure.